home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1997 July / EnigmA AMIGA RUN 20 (1997)(G.R. Edizioni)(IT)[!][issue 1997-07 & 08][EAR-CD IV].iso / lightwave / lwmlist / 94.lightwave-08 / 000471_owner-lightwave-l _Tue Aug 23 07:32:09 1994.msg < prev    next >
Internet Message Format  |  1994-09-05  |  4KB
  1. Return-Path: <owner-lightwave-l>
  2. Received: by mail2.netcom.com (8.6.9/Netcom)     id GAA13692; Tue, 23 Aug 1994 06:57:50 -0700
  3. Received: from corsa.ucr.edu by mail2.netcom.com (8.6.9/Netcom)     id GAA13685; Tue, 23 Aug 1994 06:57:48 -0700
  4. Received: (from jcsky@localhost) by corsa.ucr.edu (8.6.9/8.6.9) id GAA27169 for lightwave-l@netcom.com; Tue, 23 Aug 1994 06:57:12 -0700
  5. From: joe solinsky <jcsky@cs.UCR.edu>
  6. Message-Id: <199408231357.GAA27169@corsa.ucr.edu>
  7. Subject: Re: Particle effectuators
  8. To: lightwave-l@netcom.com
  9. Date: Tue, 23 Aug 1994 06:57:12 -0700 (PDT)
  10. In-Reply-To: <9408222322.1.17134@cup.portal.com> from "Jeric@cup.portal.com" at Aug 22, 94 11:22:53 pm
  11. X-Mailer: ELM [version 2.4 PL23]
  12. MIME-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 3104      
  16. Sender: owner-lightwave-l@netcom.com
  17. Precedence: bulk
  18. Reply-To: lightwave-l@netcom.com
  19.  
  20. >     Would there be any merit to having "magnets" and "repulsars" in
  21. > LAYOUT?  These would be points that have a displacement effect on
  22. > object geometry.
  23.  
  24. I like it, how about everyone else?
  25. A noteworthy feature (just a toggle for the user, but a different programming
  26. attack) would be to switch between deforming the object, or keeping it rigid.
  27. More to the point, level settings would also be sage.  A use for keeping the 
  28. body rigid or semi rigid would be to introduce a "collision" effect that 
  29. even though would not be full physics collision detecting (like what is in real
  30. 3D), but would at least provide a built-in manner for the artist to mimic such
  31. behaviour.  I think the physics are clear on this algorithm already, but if 
  32. anyone wants it, I can attempt to write it up.  Gotta do something with that
  33. $75. text book I still have...
  34.  
  35. > 
  36. >     By having "magnets" treated as a particle cloud, for instance, we
  37.                          ^^^^^^^^
  38. I like clouds!
  39.  
  40. >     Effect only happens to polys whose normals are within X amount of
  41. >     a given vector--and inverse. 
  42. > 
  43. >     Effect only happens to specific polys, i.e. polys with a given
  44. >     surface name (multiple names).
  45.  
  46. That second line about defining affected polygons seems... tedious.
  47. Being kinda new to the toaster (but not 3D), may I ask if objects can have
  48. multiple surfaces?  Having poured over the notes on the format of the object,
  49. I would say no. Am I correct?
  50. If this is so, you would find yourself seriously redefining pre-existing 
  51. objects to be compatible with this feature.  What I think might be a better
  52. technique would be to employ whatever picking (gosh, is that an imagine term?)
  53. methoods fit the user's fancy, then if you wanted to treat it as a surface, force
  54. the user to save the object as a new file, and with that new save, create the
  55. redefined surfaces.  This way, the artist would not have to model with the 
  56. magnet and repulser forces in mind.
  57.  
  58. With the first line, within the radius X, the effect should be able to occur in
  59. a linear fashion (everything affected within the sphere at the same rate) or
  60. using the ol' distance formula 1/x^2 .  Depending on how enthusiastic your
  61. programmers are, see if they are willing to support multiple geometries for
  62. the radius of influence (gosh, is that another Imagine term? shame on me!),
  63. such as a rectangular prism as opposed to just a sphere.
  64.  
  65. Of course,the problem with all these cool features is the learning curve and
  66. the documentation.  Although it is an odd approach, write the documentation
  67. before the algorithm.  Try to come up with a metaphor for what your algorithm
  68. does.  Apply it to a real world concept (or multiple ones).  Say it is like a
  69. magnet, but go into it.  If you think about it, your documentation is the only
  70. chance you will have to prep the user on your tools.  While they are reading,
  71. if what you write is easy to understand, inventive, and clear, the user should
  72. hopefully be inventing ideas and planning the use of these tools during the
  73. process of understanding it all.
  74.  
  75. -Joe Solinsky (who writes really long messages for someone who should be doing 
  76. his math homework)